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ABSTRACT 

In this paper, we present our vision of the integration of 
human factors engineering into the software development 
process. The aim of this approach is to improve the quality 
of software and to deal with human errors in a systematic 
way. 

Categories and Subject Descriptors 

D.4.5 [Reliability]: Fault-tolerance; D.2.5 [Software En¬ 
gineering]: Testing and Debugging 

General Terms 

Reliability, Verification 

Keywords 

Human Error, Human Factor, Software Engineering, Soft¬ 
ware Testing, Fault-Tolerance 

1. INTRODUCTION 

An appropriate system interface allowing correct human com¬ 
puter interaction is just as important as correct, error-free 
behaviour of the developed system. Even if the system we 
develop behaves in an ideal correct way (i.e., according to 
its requirements specihcation), this does not help much in 
the case the system interface is unclear to the user or is too 
complicated to be used in a proper way. As per statistics 
presented in [^, the human is responsible for 30% to 60% 
the total errors which directly or indirectly lead to the acci¬ 
dents, and in the case of aviation and traffic accidents, 80% 
to 90% of the errors were due to human. Thus, it is nec¬ 
essary to have human factors engineering as a part of the 
software development process. 

There are many dehnitions of human factors, however most 
of them are solely oriented on human-machine operations in 
terms of system and program usability, i.e. on those parts 
that are seen by the (end-)user, but not by the requirements. 
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specihcation and verihcation engineers. Nevertheless, many 
problems during the engineering phase are almost the same. 

The fundamental goal of human factors engineering is to 
reduce errors, increase productivity and safety when the 
human interacts with a system, cf. [^. Engineering psy¬ 
chology applies psychological perspective to the problems 
of system design and focuses on the information-processing 
capacities of humans. It is essential to collect the error in¬ 
formation systematically, to develop an error taxonomy and 
to hnd on this basis a solution for preventing errors of this 
kind. Thus, the fault-tolerance of software and systems en¬ 
gineering should be analysed not only from hardware and 
software side, but also taking into account human factors 
and Human-Computer Interaction (HCI) analysis. 

In this paper, we discuss our ideas on the software relia¬ 
bility improvement by the integration of the human factors 
engineering into the development process, from requirement 
engineering and modelling to the testing of software. We 
propose to optimise of the requirements inspection methods 
and the modelling methods/tools using the analyse of the 
human errors that arise during the RE and modelling phases. 
We also propose to extend the classical testing techniques 
by the human factor analysis, especially focusing on the hu¬ 
man error detection and structuring. By predicting what 
types of faults are more likely to be triggered or introduced 
by users and/or programmers, we design testing strategies 
specihcally for detecting these fault types. In addition, by 
analysis of the human usage and development history, we 
can prioritise the regression test cases based on the analy¬ 
sis results, aiming at detecting more faults earlier when the 
software is evolved. 


2. BACKGROUND: HUMAN FACTORS 

There are many applications of formal methods to analyse 
HCI and to construct user interfaces, e.g. [^, as well as a 
number of approaches on the integrating h uma n interface 
engineering with software engineering, e.g., [^|^, but the 
held of application of human factors to the analysis and 
to the optimisation of formal methods area is still almost 
unexplored. However, there are many achievements in the 
HCI research that could be applicable within the formal lan¬ 
guages as well as verihcation and specihcation engineering 
tools. For example, the ideas of the usage-centered approach 
for presentation and interaction design of software and Web- 
based applications were introduced in [^ |^ . 


Originally, the research of human factors and HCI was ini¬ 
tiated and elaborated because of mistakes in usage and de¬ 
velopment of safety-critical systems rather than for the de¬ 
velopment of entertainment or every-day applications. For 
example, one of the widely cited HCI-related accidents in 
safety-critical systems are the accidents involved massive 
radiation overdoses by the Therac-25 (a radiation therapy 
machine used in curing cancer) that lead to deaths and se¬ 
rious injuries of patients which received thousand times the 
normal dose of radiation 13 . The causes of these ac¬ 
cidents were software failures as well as problems with the 
system interface. Specifying safety-critical systems, e.g. in 
the automotive domain , it is not enough to use con- 
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trolled languages and semiformal languages - the precise 
formal specification is essential to ensure that the safety 
properties of the system really hold. Moreover, this should 
be integrated in the development methodology, preferably 
supported by a tool chain, cf. [23|. 


Speaking about human factors we mostly focus on techni¬ 
cal aspects; this idea, applied to the formal methods, is of¬ 
ten called Engineering Error Paradigm . Human factors 
that are targeted by the Engineering Error Paradigm (EEP) 
typically include the design of human-computer interface as 
well as the corresponding automatisation. By this paradigm 
humans are seen as they are almost equivalent to software 
and hardware components in the sense of operation with 
data and other components, but at the same time humans 
are seen as the “most unreliable component” of the total 
system. This implies also that designing humans out of the 
main system actions through automatisation of some system 
design steps is considered as a proposal for reducing risk. In 
the case of design of safety-critical systems, this means au¬ 
tomatic translation from one representation kind to another 
one, e.g., between two formal languages or between two in¬ 
ternal representation within some tools. 


Another important view of the EEP is that human errors 
often occur as a result of mismatch in HCI and overestima¬ 
tion of physical capabilities of a person. With other words, 
we have to consider in the design process the aspects of hu¬ 
man performance and reliability. In the case of models and 
specifications, we have to focus on clearness and readabil¬ 
ity. Eor these reasons we have to analyse the achievements 
of HCI approaches to apply their ideas for the development 
of the interface between the software/verification engineers 
and the formal methods or tools they apply. The Individual 
Error Paradigm focuses on understanding the reasons 
why people make mistakes or commit unsafe acts, and then 
tries to eliminate those reasons. 


In the next section we discuss these aspects in the relation to 
requirement engineering (RE), modelling and testing phases 
of the software development process. 


3. HUMAN-ORIENTED DEVELOPMENT 

The use of structured error information helps to understand 
the real problems in the requirements documents and signif¬ 
icantly improves the effectiveness of the early detection and 
elimination of faults in software artefacts, cf. [^. Thus, 
to embed a methodology for human error analysis into the 
software engineering process, we have to classify the errors. 
There are a number of approaches in this field. Eor exam¬ 


ple, introduces a method for selection of error types and 
error production mechanisms. A review on the strategies for 
the human factor taxonomies is presented in [^. 

The studies on the software requirements inspections 
have shown that the humans ability of detecting inconsisten¬ 
cies in requirements document is affected by their learning 
style, i.e. the ways with which an individual characteris¬ 
tically acquires, retains and retrieves the information. We 
suggest to extend these approach to the implementation and 
testing of the software, as the software testing teams have 
similar tasks and problems to the requirements inspection 
teams. 

Eigure ^ presents the general idea of our approach on the 
human-oriented software development. A basis for optimi¬ 
sation of the requirements inspection methods and the mod¬ 
elling methods/tools is provided by the analysis of typical 
errors that arise during the RE and modelling phases respec¬ 
tively. The test case prioritisation is performed using the 
analysis of typical errors that arise (1) during modelling and 
implementation phases, (2) when the user interacts with the 
software. The RE, modelling and implementation phases, as 
well as the phase while the user interacts with the software, 
have different sets of typical errors. However, a taxonomy 
between these sets could be useful to improve the software 
development process. Eor example, some types of the er¬ 
rors which arise during the modelling phase can hardly be 
prevented by optimisation of the modelling methods/tools. 
Thus, we have to specify the corresponding test cases and 
take this into account during the test case prioritisation. 




Figure 1: Human-Oriented Software Development 



































Software reliability is usually defined as the probability for 
a certain system to perform its intended functions and oper¬ 
ations for a given period of time in a specified environment. 
It is always a challenging job to achieve highly reliable soft¬ 
ware. There are many engineering techniques to handle soft¬ 
ware faults, the main cause of low reliability. The four typi¬ 
cal families of software reliability engineering techniques 
are fault prevention, fault removal, fault tolerance, and fault 
forecasting. Fault prevention aims to avoid the occurrences 
of faults when constructing the software system (in our case, 
by optimisation of the methods for requirements inspections 
and modelling). The major tasks for fault removal are to 
detect and remove existing faults. Testing is the main tech¬ 
nology for fault detection. Fault toleranee provides a mech¬ 
anism that enable a system to perform normally in spite of 
the occurrence of faults (in our case, by analysis of the errors 
in HCI). Fault foreeasting targets at estimating the presence 
of faults, which can be achieved by reliability modelling. 

3.1 Human-Oriented RE and Modelling 

In our previous work on human factors engineering, we fo¬ 
cused on the human factor aspects in application to the for¬ 
mal methods used within the RE and modelling phase of a 
system development process . A software system is 

usually developed iteratively, the requirements specifications 
can be updated many timed during the development process. 
It is hard to keep up to date a readable requirements specifi¬ 
cation, if the system model or implementation is frequently 
changed during the modelling/implementation phase of the 
development. This problem could be solved by appropriate 
automatisation. For example, in a (semi-)formal speci¬ 
fication is generated from the system model automatically, 
every time the model is updated. Howerver, this does not 
solve the problem with fault-detection in the requirements 
document in the first iteration of the development process, 
where the system model does not exists. 

3.2 Human-Oriented Testing Strategies 

3.2.1 Human-oriented fault-based testing 

It is widely acknowledged that testing cannot ensure that a 
program can be fault-free, unless all possible test cases have 
been exhaustively executed, which is practically impossible. 
However, a test suite can be specifically designed such that a 
program can be guaranteed to be free of one particular type 
of fault. A testing strategy serving for such a purpose is 
termed as fault-based testing [^[^. One of the oldest and 
also the most typical fault-based testing methods is domain 
testing [^. Traditionally, the input space of a program 
can be divided into a set of disjoint domains, each of which 
represents a particular path of the program. A domain error 
refers to the defect located in a decision or condition of a 
program. To detect domain errors, test cases are required to 
be selected from on and near the boundaries of every domain 
inside the input space. 

Fault-based approach has also been widely applied into the 
test case selection based on Boolean specifications, cf. [25| . 
Boolean expressions are commonly used to describe the de¬ 
cisions and conditions inside a program, and different types 
faults can be made on the Boolean expressions, such as “an 
operator is mistakenly replaced by another type of opera¬ 
tor”, “a term is mistakenly omitted”, etc. Various strategies 


have been proposed to guarantee the detection of certain 
fault types. 

We propose that human factors be considered in designing 
fault-based testing aiming at enhancing the testing effective¬ 
ness. There exist infinite number of fault types; thus, it is 
impossible to exhaustively examine all types of faults. How¬ 
ever, by examining the behaviours of end users, we would 
be able to predict which types of faults are more easily to 
be triggered when the software is used. In addition, we can 
analyse the programming styles of developers to anticipate 
which fault types are more likely to be introduced in the 
development process. Based on the analysis results, we can 
determine some specific types of faults that need more at¬ 
tention in the testing, and hence design strategies that are 
specifically effective in detecting these fault types. 

3.2.2 Human-oriented test case prioritisation 

Regression testing [^, which re-runs previously executed 
test cases, is a necessary and important process when changes 
have been made to software systems. Due to the rapid evolu¬ 
tion of software, it has become critical to ensure a high effec¬ 
tiveness of regression testing. A regression testing approach 
means the prioritisation of the existing test cases in a cer¬ 
tain order such that the test cases with higher effectiveness 
can be executed earlier. Various prioritisation techniques [H 
have been proposed to maximise the fault-detection effi¬ 
ciency: A prioritisation technique is considered to be more 
effective than the other if it can reveal more faults earlier. 
A typical approach to test case prioritisation is based on the 
information provided by the test execution history on previ¬ 
ous versions of the software under test, such as the coverage 
achieved by each test case on previous versions. 

In our research, we propose that the development and usage 
history of the software under test should also be investigated 
and applied in guiding the test case prioritisation. Typically, 
an user/programmer makes similar mistakes as usual when 
using/developing the software, as it is difficult to change 
one’s working style. As such, if a test case t reveal a fault in 
the original version, it is very likely that t and/or those test 
cases similar to t also cause the new version to fail. Based 
on the human-oriented fault history, we can further improve 
the effectiveness of test case prioritisation. 

It is also likely that users with a similar background make 
similar mistakes, thus we can categorise the errors per groups 
of users. The identification of these mistakes and clarifying 
them not only by error types but also by the user groups, 
could (1) enable us to construct automatic models for gener¬ 
ating test cases, (2) be useful for prioritising test cases based 
on their coverage in detecting common faults in the usage 
history of the software. 

4. CONCLUSIONS 

In this position paper we have introduced our ongoing re¬ 
search on incorporation of the human factors engineering 
into the software development process. Human factors anal¬ 
ysis can be used not only to improve quality of requirement 
specification and readability of software models, but also to 
guide various testing tasks. On the level of requirements 
specification and system modelling, we mostly focus on the 
readability and understandability aspects. On the level of 


software testing we suggest to apply human-oriented strate¬ 
gies to improve the fault-detection effectiveness. Therefore, 
we suggest to analyse what types of faults are more likely to 
be triggered or introduced by users and/or programmers, to 
design testing strategies specifically for detecting these fault 
types. 
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